AWS IoT SiteWise 利用料金の見積もり方法

AWS IoT SiteWise 利用料金の見積もり方法

Clock Icon2022.06.06

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

どのようなサービスでも事前に利用料金を把握することは大事です。
今回 AWS IoT SiteWise の料金を見積もる際に課金の仕様で難しい部分があったので、見積もり方法と合わせてご紹介したいと思います。

見積もり方法

AWS IoT SiteWise の見積もり方法は次の2種類があります。

  • 公式の料金サイトを参照して手動で計算する
  • 公式のカリキュレータ(Excel)を使用して計算する

(残念ながら本記事の執筆時点では SiteWise は AWS Pricing Calculator に対応していません。今後のアップデートに期待です。)

公式の料金サイト

AWS IoT SiteWise の利用料金に関する情報は以下で公開されています。

このページには、どの項目でどういうレートで課金が発生するのかという説明と、見積もり例が 7 種類も掲載されているので、課金の仕様を把握するのに役立ちます。

公式のカリキュレーター

上記のページを見れば手動でも頑張れば見積もれそうですが、できれば細かい計算はしたくないものです。そこで上記の料金サイトには「AWS IoT SiteWise 見積りツール」というものが紹介されており、そのリンクから Excel 形式のカリキュレータをダウンロードすることができます。

01-link-for-calculator

ファイルを開くと下記のように、右側に利用量やデータサイズなどのパラメータを埋めていくことで、左側に月額と年額が自動計算されて表示される仕組みになっていることが分かります。

02-shot-calculator

カリキュレータの項目(利用詳細)

重要な入力項目は「黄色」のセルになります。各項目の意味については該当のセルを選択することで説明のコメントを見ることができます。それぞれの項目について詳しく見ていきましょう。

09-usage-detail-main

Total Number of Sites

デバイスや設備機器が置かれる場所や拠点の数です。
例として、工場や倉庫などがあります。例えば、対象の工場が「東京工場」と「大阪工場」の2箇所であれば、ここには「2」を入力します。

Average Number of assets per site

拠点あたりのデバイスや機器(アセット)の平均値です。
データを取得するデバイスや機器の数と考えるとよいでしょう。工場であれば「データ取得したい PLC の数」などが該当します。

Average Number of Measurements per asset

SiteWise に送られてくるアセットあたりのデータ数の平均値です。
つまり、データ取得するデバイスや機器あたりのデータの数です。工場であれば、PLC で取得できるデータの内、SiteWise に送りたいアイテム ID の数(タグ ID の数)になります。

Average Measurement datapoints per second

OPC UA サーバ上で 1 秒間にデータが更新される頻度の平均値です。
SiteWise ゲートウェイでは「スキャンモードの設定」により OPC UA サーバに対するデータのスキャン方法が変わります。デフォルトでは「サブスクライブ」方式なので、データ更新が発生したタイミングで OPC UA サーバからデータを取得します。
したがって、この見積もり項目が小さいほどデータ転送量も少なくなるので、料金も少なくなります。

Average TQV size of Equipment Data in message payload (bytes)

個々のデータの平均サイズ(Byte)です。
なお、ここにある「TQV」とは、SiteWise に送るデータ構造のことで、下記のキーを持ったデータのことを 「TQV データ」と呼称したものになります。

  • T: Timestamp
  • Q: Quality
  • V: Value

SiteWise に送るデータ構造は TQV フォーマットである必要があるので、多くの場合で 150 〜 200 Byte 程度になるかと思います。

その他の項目

SiteWise では、収集したデータに対して簡単な計算で変換したデータを「変換(transform)」というアセットプロパティとして取り込む事ができます。
例えば、華氏(F)で取り込んだデータを摂氏(C)のデータに変換するなどです。

また、取り込んだデータの平均値やデータ同士を計算した値を「メトリクス」というアセットプロパティとして取り込むこともできます。メトリクスを取る時間間隔は決められたものから選択して設定します。

12-transform-metrics

その他の「水色のセルの項目」は少々特殊なので、それぞれ簡単に解説します。

13-other-blue-cells

Average number of measurements, transforms or metrics used to compute a metric

「メトリクス」の計算で利用する各種アセットプロパティ(測定値、変換、メトリクス)の平均の数です。
例えば、「温度A」「温度B」という2つの測定値の平均値であれば、参照しているアセットプロパティは「温度A」と「温度B」の2つなので、入力値は「2」となります。

Precentage of properties published to notifications

SiteWise では取り込んだデータを AWS IoT Core のトピックにパブリッシュすることができます。この欄では、IoT Core にパブリッシュするアセットプロパティの割合を入力します。

Number of applications (besides Monitor) retrieving data

SiteWise Monitor のような SiteWise に蓄積されたデータを参照するアプリケーションの数を入力します。ただし、SiteWise Monitor はカウントの対象外なのでSiteWise Monitor を使う場合は、この欄は「0」とします。その他ユーザー側のカスタムアプリケーションから参照する場合は、そのアプリケーションの数を入力します。

ここで入力した値に応じて「メッセージング」の料金が変動します。

14-application-messages

SiteWise Monitor のカリキュレータの項目

カリキュレータにある SiteWise Monitor の項目には次の 4 つがあります。

  • Number of users
  • Number of dashboards per user
  • Number of measurements, transforms & metrics per dashboard
  • Average number of hours of usage per user per day

料金ページの説明にもあるように、SiteWise Monitor の課金対象は「SiteWise Monitor の月間アクティブユーザーの数」 です。
そのため「Number of users」のみが SiteWise Monitor の課金に影響します。実際に他の項目を入れてみても料金に変動はありません。

07-monitor-price

ただし、他の3項目に意味が無い訳ではありません。
SiteWise Monitor のような可視化アプリケーションや、自前のカスタムアプリから SiteWise のデータを取得して利用するような場合は、別途データに対するクエリ料金が発生します。

これら3項目においては、SiteWise Monitor を例にして「どれくらいのボリュームの、どんなデータを、どんな頻度で利用するか」を入力します。
その3項目を入力しても、SiteWise Monitor の料金は変わりませんが、入力値(SiteWise Monitor 利用ユーザー数含む)を元にクエリ料金が計算されて「メッセージング」の料金が変動します。

11-monirot-messaging

それぞれの意味は次のとおりです。

Number of users

SIteWise Monitor を利用する全ユーザー数です。

Number of dashboards per user

1ユーザーが利用するダッシュボードの数です。

Number of measurements, transforms & metrics per dashboard

ダッシュボードあたりのデータの測定値、変換したデータ、メトリクスの数です。

Average number of hours of usage per user per day

1ユーザーが1日に SiteWise Monitor を利用する平均時間です。

ここまでの説明を通して「利用詳細」の箇所で説明した通り「メッセージング」の料金は次の項目に影響することも分かりました。

  • SiteWise 以外のデータ参照アプリケーションの数
  • SiteWise Monitor の利用ボリューム
    • ユーザー数
    • ダッシュボード数
    • アセットプロパティ数
    • 利用時間

15-messages-costs

SiteWise Edge のカリキュレータの項目

最後は SiteWise Edge の料金です。
SiteWise ゲートウェイでは、次の 2 種類のパッケージをインストールして利用することができます。

  • データ収集パック
  • データ処理パック

このうち「データ収集パック」はデフォルトでインストールされるもので、OPC UA サーバからデータを収集するためのパッケージです。
一方で「 データ処理パック」は、収集したデータをゲートウェイ上で処理、可視化することができるパッケージです。

08-sitewise-edge

「データ収集パック」は無料で使えるので、カリキュレータでは利用する「データ処理パック」の数を入力します。

注意点(ハマった点)

さて、記事の始めの方で「手動で計算するのは辛いのでカリキュレータを使いたい」と書きました。しかし、試しに料金サイトの「例1」の内容をカリキュレータに入力すると、料金サイトとは異なる金額が表示されてしまいました。

カリキュレータは SiteWise ゲートウェイ利用が前提

料金がずれる原因は、カリキュレータにある「Messaging」のコメントに答えがありました。

03-messaging-comment

If the frequency of ingestion of equiment datapoints is greater than one every 10 seconds, SiteWise gateway automatically packs upto 10 data points to minimize overall messaging and data processing costs. AWS IoT SiteWise meters messages at increments of 1kB of equipment data.

上記のとおり、データポイントの取り込み頻度が10秒間隔よりも多い場合、SiteWise ゲートウェイが自動的にデータ処理をパッケージングすることで「メッセージング」および「データ処理コスト」を最小化します。

この動作の詳細は下の5項目の数字を乗算したものになりますが、複雑な計算式が含まれていることが分かります。 計算式が複雑なので、計算の意味については「データの取り込み頻度が10秒間隔よりも多いと安くなる」という程度で理解しておくと良さそうです。

  • Total Number of Sites
  • Average Number of assets per site
  • Average Number of Measurements per asset
  • Average Measurement datapoints per second
  • 1ヶ月の秒数
  • (IF((1/[Average Measurement datapoints per second])<=10,MAX(0.1,1/CEILING.MATH(1/(CEILING.MATH(([Average Measurement datapoints per second]*10*[Average TQV size of Equipment Data in message payload (bytes)])/1024)*1/ROUNDDOWN([Average Measurement datapoints per second]*10,0)))),1))

SiteWise ゲートウェイを使わない場合

逆に、SiteWise ゲートウェイを使わず IoT Core 経由や API を用いて SiteWise にデータを送る場合は、上記の理由によりカリキュレータでは試算できません。
そのような場合は、公式ページを元に手動で算出する必要があります。

カリキュレータは Data Export to Amazon S3 が有効

また、次の「Data Export to Amazon S3」の項目も注意が必要です。
SiteWiseはデフォルトで S3 へのエクスポートが無効になっており、ユーザーにより有効化できるようになっています。
しかし、カリキュレータでは「エクスポートが有効になっていることが前提」で計算に組み込まれます。カリキュレータでエクスポートを無効にして計算することはできないので、エクスポートしない場合の料金が知りたければ、合計額から手動で除く必要があります。

04-data-export-s3

そのようにコメントにも記載されています。

05-data-export-comment

サポートされるリージョン

最後にハマる程のポイントではないですが、カリキュレータでは Tokyo リージョンがありません。

06-select-region

Tokyo リージョンの料金は 「Asia Pasific (Singapore)」と同じなので、Tokyo リージョンでの試算をする場合は Singapore リージョンを選択するとよいでしょう。

注意点のまとめ

以上の通り、カリキュレータを使う場合は次の点に注意しましょう。

  • カリキュレータは SiteWise ゲートウェイの利用が前提になっている
  • IoT Core や API でデータ送信する場合は手動で料金計算する
  • S3 へのデータエクスポートの料金が含まれる
  • Tokyoリージョンの計算は Singapore リージョンを使う

見積もり上のポイント

SiteWise の課金項目の内、気をつける項目は「メッセージングコスト」です。
メッセージングはオプション機能ではなく標準的に発生する課金なので、取り込むデータ量が多くなると高額になりがちです。

例えば、工場にある PLC 50 台から取れる1秒間隔のデータ 20 点を SiteWise に取り込み、可視化したデータを 5 人で見る場合、その月額料金は「約1,300 ドル」になります。

このうち、メッセージング料金は約 690 ドルです。次に大きいのは「データ処理」費用の 約340 ドルです。「データ処理」費用は「メッセージング」費用と連動するため、メッセージング料金が全体の金額に直結します。

では、どんな点を考慮すればよいでしょうか?

本当にリアルタイムな可視化が必要かどうか

SiteWise Monitor を使うとユーザーが可視化アプリケーションを別途構築しなくても、簡単な設定だけでリアルタイムにデータを可視化することが可能です。
とはいえ、取得できる全てのデータを闇雲に入れてしまうと、高額な料金が無駄に発生してしまいます。

リアルタイムな可視化が必要なデータのみ SiteWise に送り、それ以外は Stream Manager などを使って Kinesis Data Streams や IoT Analytics などに送って S3 などのストレージに保存するような組み合わせのアーキテクチャが望ましいと思われます。

料金例

最後に仮の環境を想定して見積もりを行ってみたいと思います。前提は下記のとおりです。

  • ①拠点数:1拠点
  • ②PLC の数:10 個
  • ③リアルタイムに可視化したいデータ点数 / PLC(アイテム・タグ数):10 点
  • ④OPC UAサーバ上のデータ更新頻度の平均:1秒
  • ⑤個々のデータサイズ:150 Byte
  • ⑥アセットあたりのデータ変換(transform)を行う対象の平均:1個
  • ⑦アセットあたりの5分間隔のメトリクスを取る対象の数:1個
  • ⑧SiteWiseのデータを使うアプリケーション:SiteWise Monitor のみ

16-example-usage-details

  • ⑨SiteWise Monitor 利用ユーザー:5人
  • ⑩ユーザーあたりのダッシュボードの数:1個
  • ⑪SiteWise Monitor ダッシュボードに表示する計測値、変換値、メトリクス値の数:10 個
  • ⑫1人の利用ユーザーが1日に SiteWise Monitor を利用する時間:2時間
  • データ収集とデータ送信は SiteWise ゲートウェイを利用する
  • ゲートウェイ上でデータ処理(計算や可視化)は行わない

17-example-sitewise-monitor

この前提による月額は「202.95 USD」となります。

18-toral-costs

内訳の詳細は下記のとおりです。

19-costs-details

最後に

SiteWiseは、IoT データの収集・送信・可視化 / 通知 をトータルで提供してくれる強力なサービスですが、その分コストがやや高めとなっています。

まずは小規模な環境で試してみて、リアルタイムな可視化が必要なデータの洗い出しや、可視化を通して業務上の本質的な課題の抽出などに活用していくのが良さそうです。

小規模に始めるときの費用試算として、本記事がお役に立てれば幸いです。

以上です。

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.